home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000124_gadia@cs.iastate.edu _Thu May 13 20:04:09 1993.msg < prev    next >
Text File  |  1996-01-31  |  3KB  |  80 lines
  1. Message-Id: <199305140104.AA28613@optima.cs.arizona.edu>
  2. Received: from ren.cs.iastate.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA28613; Thu, 13 May 1993 18:04:09 MST
  4. Received: by ren.cs.iastate.edu
  5.     (16.8/16.2) id AA15862; Thu, 13 May 93 20:04:10 -0500
  6. From: Shashi K. Gadia <gadia@cs.iastate.edu>
  7. Subject: Benchmark/"Taxonomy"
  8. To: tsql@cs.arizona.edu
  9. Date: Thu, 13 May 93 20:04:09 CDT
  10. Cc: gadia@cs.iastate.edu
  11. Mailer: Elm [revision: 70.30]
  12.  
  13. I see that a lot of effort has gone 
  14. in to "taxonomy".  Unfortunately 
  15. there is very little here that I agree 
  16. with. 
  17.  
  18. A. It is very narrowly focused, and 
  19.    disregards the notion of orthogonality.  
  20.    If there are 4320 different categories, 
  21.    I feel there is something fundamentally 
  22.    wrong with the approach. 
  23.  
  24. B. I find the option "imposed" in Figure 2 
  25.    quite questionable.  It is to be taken 
  26.    with a grain of salt.  This amounts to 
  27.    cooking new information rather than 
  28.    retriving information existing in the 
  29.    database.  I can not see how we can elevate 
  30.    it to the same level as other options. 
  31.  
  32. C. The option "none" under the valid-time 
  33.    component raises an important question. 
  34.    This allows timestamps to be erased from 
  35.    a relation.  So does it mean we have two 
  36.    types of relations: temporal relations 
  37.    and "non-temporal" relations?  If these 
  38.    non-temporal relations can be computed, 
  39.    can they be mixed with temporal relations 
  40.    to answer additional queries?  If no, 
  41.    then the non-temporal relations are only 
  42.    terminal, and I have no problem with this.
  43.    But if they are not terminal, then you 
  44.    could retrieve misleading information.  
  45.    Its better to be conservative and simply 
  46.    not allow nonterminal-nontemporal 
  47.    relations.  Otherwise every participant 
  48.    should take an clear stand over this 
  49.    issue.
  50.  
  51. D. Although the remarks in this subsection 
  52.    concern our approach, but it also relates 
  53.    to most other approaches, perhaps in different 
  54.    measures.
  55.  
  56.    If I disregard the following options: 
  57.  
  58.       imposed          from Figure 2, 
  59.       ordering-based   from Figure 4,
  60.       interval         from Figure 4, 
  61.  
  62.    then in our TempSQL there is only 1 and 
  63.    NOT 4320 different categories, all handled 
  64.    in a uniform manner.  This leaves me wondering 
  65.    that if I want to propose a query, why should 
  66.    I have to bother about associating one of the 
  67.    4320 categories! 
  68.  
  69. Summary.
  70. --------
  71. I appreciate a need for a structure.  However, 
  72. I do not know what that structure is, but 
  73. if there is one, I strongly feel that it will 
  74. come from English (a natural language).  
  75. The bottom line is that if someone 
  76. suggests a new query form(s), we are obliged 
  77. to include it in the benchmark, irrespective of 
  78. whether we have understood the underlying 
  79. classification. 
  80.